[00:01.760 --> 00:06.480]  Hi there. I hope everyone is joining DEF CON Safe Mode. This should be one of the talks
[00:06.480 --> 00:09.420]  near the end of the conference. I'm pretty sure it's the last one for the Car Hacking
[00:09.420 --> 00:14.520]  Village. So I hope everyone's done well and survived this long. We don't certainly have
[00:14.520 --> 00:17.920]  to worry about some of the main hazards that you would normally have to worry about during
[00:18.080 --> 00:23.840]  a DEF CON because everyone's remote. The concepts I'm going to present in this were originally
[00:23.840 --> 00:29.060]  intended to be part of the main Tesla reverse engineering talk that I've done. But when
[00:29.060 --> 00:35.080]  everything was shortened due to going remote, I decided to actually split these individual
[00:35.080 --> 00:40.660]  topics off and do them as a separate talk. The things I'm going to cover here don't require
[00:40.660 --> 00:47.500]  that you actually have listened to the main talk. However, it certainly wouldn't help
[00:47.500 --> 00:51.600]  if you've actually already seen that or go back and watch it if some of the concepts
[00:51.600 --> 00:54.960]  are on here. They're all really just going to build on some of the stuff I've already
[00:54.960 --> 01:00.240]  talked about, but they're also going to cover DVC and ODX and some of the firmware stuff
[01:00.240 --> 01:07.360]  that would really stand on its own as well. So a little bit about me. My name is Patrick
[01:07.360 --> 01:13.900]  Kiley. I'm a Principal Security Consultant at Rapid7. I've been with them for quite a
[01:13.900 --> 01:20.520]  bit of time. I started with them in 2013. I've been working more recently in subjects
[01:20.520 --> 01:26.940]  such as avionics security. I did some research that I released last year on CAN bus and avionics,
[01:26.940 --> 01:32.480]  and I've actually done quite a bit of other poking around with avionics systems as an
[01:32.480 --> 01:37.420]  item that I've focused on. And of course, researching the Tesla, I'm interested in Internet
[01:37.420 --> 01:42.520]  connected transportation platforms, hardware hacking, IoT, done quite a bit of that, and
[01:42.520 --> 01:47.540]  of course, autonomous vehicles and CAN bus. Tesla not being one of the autonomous vehicles
[01:47.540 --> 01:51.860]  I've looked at, just autonomous vehicles in general, it's a subject that I'm interested
[01:51.860 --> 02:01.690]  in. So topics we're going to cover here. First, we're going to go over the Model S architecture
[02:01.690 --> 02:07.710]  just briefly again. From there, again, I cover a little bit about the Tesla BMS, and then
[02:07.710 --> 02:13.750]  we're going to go into CAN bus DVC files and some of the information that we can get from
[02:13.750 --> 02:18.330]  that if we actually have a DVC file on your reverse engineering vehicle. The screen that
[02:18.330 --> 02:28.050]  you see here is actually from Kvaser's database editor. That's a free tool that you can use
[02:28.050 --> 02:32.010]  to basically edit and create your own DVC files. It's very helpful because you don't
[02:32.010 --> 02:37.650]  actually have to see the signal on the bus to go in and modify it, and you can actually
[02:37.650 --> 02:42.170]  trim it down. I use this to actually trim down the amount of signals that were present
[02:42.170 --> 02:52.490]  on a mobile app for a little wireless dongle called a Panda that was connected to the BMS,
[02:52.910 --> 02:58.970]  the powertrain CAN bus on the Tesla, and then actually just listen to some individual signals.
[02:59.110 --> 03:03.470]  Trying to put this entire DVC file on there would just basically crash the mobile app.
[03:03.470 --> 03:07.750]  It can't handle that much. However, trimming it down to just the signals I was interested
[03:07.750 --> 03:12.810]  in is really useful using this tool for that. So I'd encourage anyone who's interested in
[03:12.810 --> 03:17.210]  messing around with DVC to check this one out because it is free. From there, we're
[03:17.210 --> 03:25.050]  going to cover UDS and some of the routines that you're able to extract from the Tesla
[03:25.050 --> 03:29.410]  firmware and from the Tesla toolbox firmware and some of the useful things that you can
[03:29.410 --> 03:35.030]  actually do with them. I'm going to show security access and shunt calibration, the ones I actually
[03:35.030 --> 03:39.670]  use for this research because they're the ones I did the most work with, and I've got a couple
[03:39.670 --> 03:43.910]  of interactive demos for that. And then from there, we're actually going to go into a BMS
[03:43.910 --> 03:50.010]  firmware. We're going to talk about the things that I learned from trying to reverse the firmware
[03:50.010 --> 03:56.190]  itself, the nature of the firmware, the type of the way it's stored, and then some information
[03:56.190 --> 04:05.010]  on the TMS320, which is the primary CPU used in the battery management system. It's also used,
[04:05.010 --> 04:13.270]  on the Model S and other Tesla models. So just a quick overview, the Tesla Model S,
[04:13.270 --> 04:19.410]  the main screen that you see to the right of the driver is actually, on the older vehicles,
[04:19.410 --> 04:23.890]  it's NVIDIA Tegra based, newer ones, it's Intel Atom. And then the instrument cluster
[04:23.890 --> 04:30.490]  is actually NVIDIA Tegra based as well. And it connects to the CID, the central display,
[04:30.490 --> 04:35.310]  over an Ethernet connector. That Ethernet connection actually connects to a service
[04:35.310 --> 04:39.230]  port, but it also connects to the security gateway. The security gateway is basically
[04:39.230 --> 04:46.910]  like a vehicle firewall. It acts as a filtering mechanism between the various CAN buses and the
[04:46.910 --> 04:53.250]  CID itself, the Ethernet. And then all the stuff that we're going to see today is actually on a
[04:53.250 --> 05:00.310]  powertrain CAN bus. A powertrain CAN bus contains the drive units, also charging, thermal control,
[05:00.310 --> 05:05.010]  and any other powertrain-related controllers all exist on that CAN bus. That CAN bus runs at
[05:05.010 --> 05:10.650]  500 kilobits a second. Other than that, it's like any other vehicle CAN bus that you've seen,
[05:10.650 --> 05:18.150]  11-bit arbitration IDs, sports UDS. And then the other CAN buses, there are like six or seven,
[05:18.490 --> 05:23.810]  but the other big ones are chassis and body. Chassis runs at 500 kilobit, body runs at 125.
[05:25.170 --> 05:38.250]  So the BMS itself, it's the TI-TMS320C2809. That is a DSP microprocessor. It takes all the various
[05:38.250 --> 05:44.870]  signals coming from voltage from the individual battery packs, from the voltage sense, from the
[05:44.870 --> 05:52.850]  temperature sensors, and then also talks CAN bus out on the chassis itself. There's a hardware
[05:52.850 --> 06:00.270]  backup to that. That's the Altera CPLD. In all the research I did, that CPLD wasn't really messed
[06:00.270 --> 06:06.790]  with at all, except for having a signal bypass, so it wasn't actually sent to the CPLD. But
[06:06.790 --> 06:12.090]  basically, it's a hardware backup to the TMS320. And for some reason, there's a software fault,
[06:12.090 --> 06:19.650]  the CPLD will still allow the battery to function while I assume the vehicle shuts down and safely
[06:19.650 --> 06:25.710]  disconnects the conductors. I've never actually seen the fault condition. I've just talked to
[06:25.710 --> 06:30.710]  some people and learned that that's really its mission in life, is to act as a hardware backup.
[06:31.390 --> 06:36.810]  There's also a few other devices. I'm going to just skip to the next slide to talk about those.
[06:37.130 --> 06:42.250]  There's a current shunt. For those of you who aren't familiar with what a shunt is, a shunt is
[06:42.370 --> 06:48.550]  a way of measuring current by measuring a voltage drop across a known resistance value. This one
[06:48.550 --> 06:53.990]  actually measures quite a bit of current. It's a pretty ingenious device, but every device actually
[06:53.990 --> 06:59.910]  has its own low level of resistance that's calibrated onto the shunt itself. The shunt
[06:59.910 --> 07:06.210]  runs STM8. There's also a pre-charge resistor. So the way the vehicle actually engages the
[07:06.210 --> 07:10.010]  contactors, it will engage one side of the contactors. I believe it's negative, please
[07:10.010 --> 07:18.310]  don't quote me on that. And then it goes through the standard low voltage cabling to slowly bring
[07:18.690 --> 07:25.870]  the vehicle up slowly, as a matter of milliseconds or microseconds, as opposed to instantaneously.
[07:25.870 --> 07:29.950]  But basically it brings the rest of the vehicle up to the same voltage as the battery before it
[07:29.950 --> 07:34.670]  engages the other contactor. And it uses the pre-charge resistor for that. Then the contactors
[07:34.670 --> 07:41.290]  themselves, in Ludicrous they are actually replaced with higher current models. This is a different
[07:41.290 --> 07:45.990]  set of contactors that I picked up off the secondary market so I can do my research. I also
[07:45.990 --> 07:55.410]  have a single BMB board on this. There are 16 of those in the model S85 and each of them has like
[07:55.410 --> 08:01.290]  six different channels that talk to the six different modules of series batteries on there.
[08:01.290 --> 08:06.930]  It also contains bleed resistors for a battery balancing, voltage measurement, temperature
[08:06.930 --> 08:12.610]  measurement, etc. And then the voltage sense wires, the ones you see on the far right, those four
[08:12.610 --> 08:16.850]  wires actually connect to the four sides of the contactors so they can detect if a contactor is
[08:18.230 --> 08:23.690]  fused. So it's basically if it welds itself closed, the voltage sense can detect that but it also can
[08:23.690 --> 08:31.870]  be used to just detect battery voltage overall. So a little bit about CAN-DBC. The CAN-DBC files
[08:31.870 --> 08:37.610]  I was able to extract from both Toolbox and the vehicle firmware. Here's what it looks like within
[08:37.610 --> 08:45.750]  Vehicle Spy after it's been imported. And you can actually see DI means Drive Inverter, DIS means
[08:45.750 --> 08:52.570]  the Front Drive Inverter. So DI is the Rear Drive Inverter, DIS is the Front Drive Inverter. You can
[08:52.570 --> 08:59.870]  actually see some different values being broadcast onto the CAN bus from this capture. And it's an
[08:59.870 --> 09:06.290]  interesting way of actually extracting the signals from this. You can actually see everything. I'm not
[09:06.290 --> 09:11.670]  even quite sure where this image came from, if it was from a running unit or just from a unit
[09:11.670 --> 09:19.550]  sitting idle, but this one actually shows the two drive inverters so I wanted to share it. This set
[09:19.550 --> 09:26.230]  of images actually shows the BMS after it was upgraded to Ludicrous. So it has different signals
[09:26.230 --> 09:32.930]  for current and power. Current is a hard limit. Once the pack has been upgraded to support Ludicrous,
[09:32.930 --> 09:40.650]  it goes from 1305 to 1516. You can see that in here is the max discharge current of 1516. However,
[09:40.650 --> 09:49.090]  the drive power max, the value you see down here is 297 kilowatts, is a variable value. It varies
[09:49.090 --> 09:55.090]  based on the state of charge of the battery, the temperature of the battery, and how much power was
[09:55.090 --> 10:00.350]  used recently. So the warmer the battery gets up to a point, that drive power max will actually
[10:00.350 --> 10:05.990]  increase. But then if the car has been stomped on for a little while, it will actually decrease.
[10:05.990 --> 10:11.190]  There's a whole leaky bucket thing that's mentioned in some of the Tesla engineering
[10:11.190 --> 10:18.470]  docs that talks about how it'll limit the amount of power if the power has been used recently. So
[10:18.470 --> 10:25.250]  it's got to wait for it to basically recharge, regenerate, and I assume cool off again before
[10:25.250 --> 10:32.910]  it brings it back. So one of the things I found that was interesting was that as soon as max
[10:32.910 --> 10:37.810]  battery power was selected, so for those of you who haven't actually been into a Model S,
[10:37.810 --> 10:45.670]  there's chill, sport, ludicrous, and then ludicrous plus. And if you don't have ludicrous,
[10:45.670 --> 10:51.230]  you have insane mode. And what I actually found right away is by monitoring the CAN bus,
[10:51.230 --> 10:57.950]  is after putting in the setting to enable ludicrous plus, the available power went up
[10:57.950 --> 11:02.670]  right away. So even though the battery had not heated up anymore from the 22 degrees Celsius
[11:02.670 --> 11:10.590]  value, instantly more power is available. It went from 439 to 452 kilowatts.
[11:11.530 --> 11:17.350]  All right, here's a screenshot from a P90DL that someone actually gave me access. Let me
[11:17.350 --> 11:22.430]  plug into the CAN bus and capture some messages as the battery was heated a little bit. And you
[11:22.430 --> 11:28.670]  can see that from this, even though the state of charge went down, it went from 93 to 91 percent,
[11:28.670 --> 11:33.370]  the amount of power went up. So it really seemed like pack temperature is the most dependent value.
[11:33.370 --> 11:41.470]  So it went from 22 to 31 and went from 454 kilowatts of power available to 480 kilowatts.
[11:41.470 --> 11:48.550]  You can also see region change went from 63 to 90. 90 appeared to be a top end static value.
[11:50.450 --> 11:58.730]  So a little bit about ODX. ODX is an ISO standard for diagnostic communication and ECUs.
[11:58.730 --> 12:06.590]  The way a lot of other vehicles, not Tesla's, work is you can have ECUs from like several
[12:06.590 --> 12:12.850]  different manufacturers and they all need to be able to communicate together within a different
[12:12.850 --> 12:19.750]  vehicle. So you might have some Bosch units or Mitsubishi units or some other different ECUs,
[12:19.750 --> 12:23.150]  but they all still need to be able to communicate with one another on the CAN bus.
[12:23.350 --> 12:29.990]  ODX is a standard that kind of aids in that. It's a standard for diagnostic communication so that
[12:31.430 --> 12:37.810]  a specific message start always means generally the same thing. And this image that you see in
[12:37.810 --> 12:44.670]  the screenshot is actually the XML file from ODX file that I actually extracted from a toolbox
[12:45.390 --> 12:50.650]  from the main talk if you follow my values that we got from there.
[12:51.290 --> 12:59.070]  So here is one of the most interesting ODX routines if you're going to start hacking on Tesla.
[12:59.070 --> 13:05.850]  Tesla's use a static key and C for security access. Not the best security practice, but it's
[13:05.850 --> 13:11.430]  the way they decide to implement it. And every single time you actually request security access,
[13:11.430 --> 13:21.190]  you can see the 2705, that's security access. It says, okay, give me the seed. The seed is 010203
[13:21.190 --> 13:25.790]  all the way up through 0F. And the response is always the same thing. So you can actually
[13:25.790 --> 13:34.650]  configure your CAN bus tool to send the same response every single time. And that's the 353437
[13:34.650 --> 13:40.830]  value C is the key. The seed can be whatever it wants, but all the ones that I've tested
[13:40.830 --> 13:45.050]  and all the modules that I've tested on this one, they all require the same key.
[13:46.610 --> 13:52.010]  And here I have a little demo actually showing how I set this up in Vehicle Spy.
[13:52.010 --> 13:58.450]  So you just send routine 27 level 5, level 5 security being the security access level.
[13:58.530 --> 14:07.590]  And then you reply with this static key as the response. There's a quick demo of it.
[14:13.310 --> 14:18.330]  Okay. Here we have a quick demonstration of security access. We have both routines
[14:18.330 --> 14:23.810]  configured within Vehicle Spy. The first thing we want to do is we want to request the seed.
[14:23.810 --> 14:28.510]  It's a very quick routine. And then from there, we actually request the key and we can see we
[14:28.510 --> 14:34.650]  can get a quick positive response. It's a very simple routine. Do it one more time.
[14:35.470 --> 14:43.210]  Request the seed. You can see the seed 1, 2, 3, 4, 5, 6, 7, 8, 9, A through F. And then,
[14:43.210 --> 14:49.430]  oh, didn't do it fast enough. One more time. Request the seed. Send the key. We got a positive
[14:49.430 --> 14:56.910]  response. A positive response shows the static value actually configured within Vehicle Spy.
[14:56.970 --> 15:03.570]  And just 303332, same things shown in the slides. And it's a very trivial thing to
[15:03.570 --> 15:09.510]  set up within Vehicle Spy. This is actually connected to a BMS system that's a test bench.
[15:15.730 --> 15:19.570]  Okay. So thank you for watching that one. I hope you enjoyed it.
[15:19.690 --> 15:23.630]  So the next one I'm going to kind of talk about is the shunt calibration.
[15:23.630 --> 15:31.890]  Shunt calibration over UDS was a separate routine. Those require basically you read the data from
[15:31.890 --> 15:36.070]  the shunt and you actually have to load special firmware onto the BMS to do this.
[15:36.710 --> 15:41.250]  The shunt calibration was a critical part of that, the ludicrous upgrade for the PD5D.
[15:41.710 --> 15:48.390]  But all you have to do is after you load the special firmware for the BMS is run
[15:50.090 --> 15:55.750]  routine22id401 and you actually get these values back. Those actually show the current value,
[15:55.750 --> 15:58.670]  but all you really need is the serial number. The serial number is then looked up
[15:59.370 --> 16:04.690]  in a Python pickle file for the values that you're going to recalibrate the shunt for.
[16:04.690 --> 16:12.670]  And you re-change CGI1, CIU1, and the CRC value to the new values. Even though you're reading it,
[16:12.670 --> 16:16.950]  the way it actually shows the write success, this is just a read screenshot.
[16:18.450 --> 16:22.350]  But once you actually get that back, there's a separate routine to write it.
[16:22.350 --> 16:28.890]  So for writing the shunt value, there's actually a write data by nanofire and there's actually
[16:28.890 --> 16:34.250]  ones for the shunt, but that's not the actual value one. The one that was supposed to be used
[16:34.250 --> 16:40.630]  to calibrate the shunt was 31 routine control. So for this particular example, if you go back,
[16:40.630 --> 16:49.910]  you can see that the old values were 41478. I'm actually going to try and change these
[16:49.910 --> 16:57.750]  and actually write them out separately. So you can see in the routine control,
[16:58.550 --> 17:06.850]  the value is set here for CGI1, CIU1, 65286. Instead of 65287, you're going to see a different
[17:06.850 --> 17:13.130]  value written and then see it actually read back in as the newer value.
[17:14.510 --> 17:21.650]  Okay, so there are several other routines that are actually included in the ODX files. If you
[17:21.650 --> 17:26.150]  actually look at this, there are ridiculous ones just even for the battery management system.
[17:26.150 --> 17:31.010]  All sorts of different ones for looking at different calibration data, looking at the
[17:31.010 --> 17:37.350]  RAM, reading that out, controlling the contactors, very dangerous to do if you're
[17:37.350 --> 17:40.810]  working on a vehicle that's actually powered on right now, because if you open the contactors
[17:40.810 --> 17:48.930]  at the wrong time, you can have some current transient issues. However, so just be careful
[17:48.930 --> 17:53.930]  with any of these, but it just found it interesting to see all the ones that were included in that.
[17:53.930 --> 17:58.650]  And then just the number of routines that were available in all the other modules were
[17:58.650 --> 18:04.330]  interesting to read out of the ODX files as well. So, next thing we're going to talk about is the
[18:04.330 --> 18:10.770]  firmware. So, all the UDS firmware updates, when they are passed on to the vehicle, when the
[18:10.770 --> 18:16.530]  car updates, they're all in Intel HEX format. They're stored on the firmware itself, at least
[18:16.530 --> 18:21.930]  on the Tegra under deploy seat artifacts v2, and then the module and the ID. So, they'll include
[18:21.930 --> 18:27.350]  all the firmware for all the various possibilities for that particular vehicle.
[18:28.050 --> 18:35.390]  And then what it does is it uses the file version underscore map 2.tsv to help the car identify
[18:35.390 --> 18:41.270]  the firmware file individually that it needs for the configuration that the car actually has.
[18:42.410 --> 18:48.570]  So, here's a little overview on how the Intel HEX format works. The first value, it always starts
[18:48.570 --> 18:55.910]  with a colon, and then the first value C20 is 32 bytes for HEX. And then we have an address
[18:55.910 --> 19:03.850]  of where that particular piece of firmware goes. And then 00, the next two values of the type of
[19:03.850 --> 19:09.010]  record, you'll see a 01 for EOF, and you'll see two other values for extended values or anything
[19:09.010 --> 19:16.050]  like that. And then you actually have data. And then the final value is a checksum. I added these
[19:16.050 --> 19:21.930]  spaces in for clarity. I tried to directly import the HEX files into IDA, but it has a problem
[19:21.930 --> 19:27.590]  reading HEX files with values this great. So, what I actually had to do is convert it to a
[19:27.590 --> 19:34.630]  TI.out format, which has the similar information on the location, but then it actually imported
[19:34.630 --> 19:45.970]  better. So, this shows the actual data sheet for the TI-TMS320-2809. It actually shows the memory
[19:45.970 --> 19:50.870]  map. And the really important thing that we need from this memory map, other than knowing where the
[19:50.870 --> 19:55.470]  different sections of memory are, the sections that are reserved because it is dual mapped,
[19:55.470 --> 20:03.030]  we're knowing where the code entry point is. So, you can actually see it. 3F7FF6 is actually where
[20:03.030 --> 20:09.370]  the initial, basically, boot-to-flash entry point. So, that basically tells us where the code entry
[20:09.370 --> 20:16.010]  point is for IDA. So, from that, we can actually import the data and actually go to this location.
[20:16.010 --> 20:23.230]  So, 7FF6 on the firmware that I'm looking at here points to 699B, and you can actually see the code
[20:23.230 --> 20:29.330]  starting. It's still not terribly helpful unless you're really, really good at reading assembly for
[20:29.330 --> 20:36.190]  the TMS320. However, it is there. It is interesting to actually see it, to see the code jump around,
[20:36.190 --> 20:43.130]  to see it all broken down into the various subroutines. And the thing that I did find very
[20:43.130 --> 20:46.670]  useful was actually doing some differential analysis. So, taking the different types of
[20:46.670 --> 20:55.810]  firmware and doing diffing on it. So, again, the assigned metadata map file tells us where the BMS
[20:55.810 --> 21:05.450]  firmware is for each config. This example, so, rear drive type one, four-wheel drive one, 4WD1
[21:05.450 --> 21:15.270]  is P85D. Rear drive type zero and 4WD1 is an 85D. So, here we're comparing the performance
[21:15.270 --> 21:20.750]  rear motor to the standard rear motor. And you can see in this firmware, there's not really a
[21:20.750 --> 21:27.930]  whole lot of differences. If you look, the last line is just the CRC value. There are some single
[21:27.930 --> 21:34.610]  bit changes at three lines in the file. And then there's this other small little section, the
[21:36.750 --> 21:47.050]  935F00 that you see in the actual major change in that. And the single motor version of the
[21:47.050 --> 21:51.770]  firmware is the same. It was just that single line that's changed. So, what I did is actually
[21:51.770 --> 21:56.030]  wanted to see if I could find this code in IDA and see where it was mapped to. And I was able
[21:56.030 --> 22:04.170]  to find it pretty easily. So, you can see within the hex, the 935F007A. This might have something
[22:04.170 --> 22:09.290]  to do with the power available. I don't know yet. I haven't changed it yet. Like I said,
[22:09.290 --> 22:13.250]  it's an ongoing project. But my goal is to actually find where the variables are that
[22:13.250 --> 22:19.050]  control the max power, the max power map, and just see if I can change them a little bit.
[22:19.190 --> 22:24.190]  See where I can actually take it. Don't think I'll ever actually do anything on a live vehicle
[22:24.190 --> 22:27.950]  just because it's too dangerous. I just want to see if I can figure this out. It's a challenge
[22:27.950 --> 22:35.110]  to me. But you can see it's actually mapped into this variable. The 935F actually comes out to 7A
[22:36.170 --> 22:42.090]  935F. Right here, IDA was able to disassemble it. You can see where it is in code. The other values,
[22:42.090 --> 22:46.890]  you can actually find they're right around there. You can see it in a couple of the locations as
[22:46.890 --> 22:53.530]  well. So, again, like I said, the next step is to modify the firmware on a bench BMS and see where
[22:53.530 --> 22:58.690]  it takes us. There's also... I want to look for some other interesting changes with the other PAC
[22:58.690 --> 23:03.790]  ID codes. See if I can actually narrow it down to some variables being located in
[23:04.830 --> 23:10.270]  other locations. And then I'm also actually taking a really close look at the hardware.
[23:10.850 --> 23:15.270]  Code Composer Studio is not the most user-friendly program unless you're really used to working with
[23:15.270 --> 23:22.850]  it. But I do have it working somewhat with a BMS. It does have JTAG exposed and available on it.
[23:24.310 --> 23:29.510]  That's some other stuff that I'm working on. But obviously somebody has figured it out because
[23:29.510 --> 23:34.130]  they're selling it as an aftermarket tuner kit for the Model 3, the all-wheel drive Model 3.
[23:34.930 --> 23:38.090]  Again, I'm just doing this because I want to explore it. I don't want to make money on this.
[23:38.090 --> 23:43.290]  I just want to figure it out. And thank you for listening to my talk. I think we're going to move
[23:43.290 --> 23:44.730]  into Q&A next.
